1. Status Quo

Currently, Propeller operates on a "Train Once, Deploy Everywhere" model. The intelligence of the system is static and created entirely outside the Propeller runtime environment.

• Training is External: the machine learning models are trained offline using Python scripts (e.g., train_model.py) on a centralized dataset.
• Models are Hardcoded: The "intelligence" of the application is frozen into the code. The training script outputs hard numbers (coefficients and intercepts), which are manually pasted or generated into a Go function (model_gen.go).

  // The "learning" is finished before this code is ever compiled
  func score(input []float64) float64 {
      return 0.0... + input[0] * 1.99... // Hardcoded constants
  }

• One-Way Flow: The Manager sends a task to the Proplet. The Proplet executes the Wasm, runs the hardcoded math on inputs, and returns a result. The Edge device acts solely as a calculator, not a learner.

2. The Problem

To achieve Federated Learning, where devices learn from local data without sharing it, the current architecture faces three blocking issues:

A. The Immutable Wasm Barrier

The current Wasm modules are stateless and immutable.

• Current State: The score function inside the Wasm binary uses fixed constants. The Wasm memory does not persist updates to these constants between executions.
• The Conflict: Federated Learning requires mutable state. The Wasm module needs to hold a set of weights, receive local data, mathematically adjust those weights (calculate gradients), and output the difference, not just a prediction.

B. The "Dumb" Manager

The Manager is currently designed as a Task Dispatcher, not a Model Aggregator.

• Current State: The Manager schedules tasks (scheduler.go), sends start commands, and stores the returned results blindly into a database (tasksDB). It treats the result as a final output (e.g., "The temperature is 25°C").
• The Conflict: In Federated Learning, the "result" from a worker is not an output, but a partial model update. The Manager needs new logic to recognize these updates, wait for a quorum of workers, perform mathematical aggregation (e.g., Federated Averaging), and issue a new global model back to the network.

C. The Disconnected Data Loop

There is no mechanism for the Edge device to utilize its own data for self-improvement.

• Current State: Data flows from the input arguments $\rightarrow$ Wasm $\rightarrow$ Output. The system assumes the "truth" (the training data) lives on the server where the Python script runs.
• The Conflict: In Federated Learning, the "truth" lives on the Edge. The Proplet needs access to local historical data or sensor readings to compute the error rate (Loss Function) of the current model, which drives the learning process. The current main.go simply takes inputs passed from the CLI/Manager, effectively ignoring the rich local data available on the device.

First training round, model "version": 1 saved

second training round, global model updated to "version": 2. We now have three versions of the global model:

• v0: The initial un-trained model (all zeros)
• v1: The result of the first round of aggregation
• v2: The result of the second round.

The weights in v2 (0.000045...) are different from v1 (0.000246...), proving that the training on the "Edge" (Proplets) is actually influencing the global model

This can be closed in favour of #117